hmm, this might change things in terms of setting up caddy for windows... I guess it's better than openssl s_server but even better solution would be to use openssl client server test like we use for some http stream tests: for example https://github.com/php/php-src/blob/master/ext/standard/tests/http/ghsa-hgf5-96fm-v528-001.phpt . Then it would work on windows too.

I remember you also commented on #16093 that the whole Caddy server setup on Windows isn't worth it.

Right now, even on Linux builds, we barely test any of the recent Curl stuff because on GitHub Actions, the Curl version is Curl 8.5 or 8.6 while Windows has 8.12.0 or so at the moment. So having these tests run on Windows will be really nice. I'm not really that familiar with OpenSSL s_server/client features, so I could use any help, or take some time to test things around. I have a Windows machine to test things, I'll try what I can :)

That said, I wonder if we really need these tests. We can test if setting a sig-alg works, setting null clears it, check if all the constants exist, etc. But beyond that, we are merely testing Curl's functionality itself. Curl surely has tests for all the variations we can think about, including various TLS backends, so perhaps we can simplify the test to see if the constants exist and if curl_setopt works. We skip the curl_exec part because once we set the options, it's Curl's job to do the actual signature negotiations. What do you think?

Sorry for the late replay. I thought about this and I guess we don't really need to test the functionality in detail. But it makes sense to have tests that test whether the option is set correctly and it does something. It's also good to test error handling so we make sure that the error is set correctly. So I think this test is actually optimal.

The only question here is whether it's better to use Caddy more (and also try to make it available on Windows) or use the streams. Thinking about it again, I guess it might not be worth invest too much time to custom server setup that we would need to do for streams. The Caddy setup is pretty small and it's not a big issue if it's not yet available on Windows. Although as you said it would be good to add it because we usually run later versions there so we can test latest functionality. I will need to update my comment as I think it would be now worth it to invest time to do the Windows Caddy setup. Although it's not a a blocker for this.

Thank you.

This test file only tries to see if the CURLOPT worked, and setting it to an invalid value actually fails the request with the expected error message. If we were to use openssl s_client, I think we can make a more meaningful test, but for a thin interface like our current CURLOPT support, I also think that a basic check is good enough. We recently added more tests for CURLOPTs that accept callable values, for which we can always be more thorough.

Do you think the rest of the PR is good to go ahead? I'd also love to help in ways I can, to add Caddy to Windows CI when we come across it.

Sorry for the late replay. I thought about this and I guess we don't really need to test the functionality in detail. But it makes sense to have tests that test whether the option is set correctly and it does something. It's also good to test error handling so we make sure that the error is set correctly. So I think this test is actually optimal.

The only question here is whether it's better to use Caddy more (and also try to make it available on Windows) or use the streams. Thinking about it again, I guess it might not be worth invest too much time to custom server setup that we would need to do for streams. The Caddy setup is pretty small and it's not a big issue if it's not yet available on Windows. Although as you said it would be good to add it because we usually run later versions there so we can test latest functionality. I will need to update my comment as I think it would be now worth it to invest time to do the Windows Caddy setup. Although it's not a a blocker for this.